I guess it's a nitpicking, but nonetheless. Should it be state method? I suppose my method as my sub is redefind on each block execution. It doesn't matter in file scope executed once, but even in that case I prefer state sub version to not get bitten by habit in block scope (ofcourse not when I really need my sub as a closure, for example). Maybe there should be my and state methods. Or my method semantics is different from my sub and similar to state sub?

state sub and our sub already exist, so state method and our method should probably also exist.

Further work to add support for the ->& operator to invoke lexical subs as methods. Currently still lacking documentation, which I shall work on today.

@tonycoz - Any additional thoughts? I see you reviewed the first round but that was before I added all the ->& operator stuff as well

Looks good except for the possibly ignorable missing semi-colon.

bison -W complains a lot, but none of the complaints are relevant to this commit (try perl regen_perly.pl -v -b 'bison -W')

The implementation of ->& in this doesn't seem to match PPC0033. In the PPC, ->& will call whatever sub is in scope, whether it is a lexical sub or a package sub.

The implementation of ->& in this doesn't seem to match PPC0033. In the PPC, ->& will call whatever sub is in scope, whether it is a lexical sub or a package sub.

Oh I see, oops. I might have misunderstood that part. I'll adjust it to match PPC0033.

Having now adjusted it to also invoke package methods (without the full MRO lookup), most of the grammar changes are no longer needed, so that lack of semicolon in perly.y is gone.
I've left the docs/perldelta commits separate for now just for ease of rebase but I'll squash each into its own actual feature commit before merge.